home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19941221-19950208 / 000040_news@columbia.edu_Wed Dec 28 21:00:14 1994.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA21514
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Wed, 28 Dec 1994 16:00:17 -0500
  3. Received: by apakabar.cc.columbia.edu id AA02154
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Wed, 28 Dec 1994 16:00:15 -0500
  5. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  6. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: Binary Uploads going through a comm server
  9. Date: 28 Dec 1994 21:00:14 GMT
  10. Organization: Columbia University
  11. Lines: 28
  12. Message-Id: <3dsjku$238@apakabar.cc.columbia.edu>
  13. References: <3dsife$ekq@dgis.dtic.dla.mil>
  14. Nntp-Posting-Host: watsun.cc.columbia.edu
  15. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  16.  
  17. In article <3dsife$ekq@dgis.dtic.dla.mil>, <Martin B. Isaksen> wrote:
  18. >I cannot upload binary files through a Penril communications server using 4E 
  19. >C-Kermit.  The same  file can be uploaded when I use a port on the back of my 
  20. >SUN (SUN OS 4.1.3) machine directly -- but when I try to go through the comm 
  21. >server it does not work. Does anybody have any clues???? (file type is set
  22. >for binary).
  23. >
  24. It probably does not affect this problem, but the current version of C-Kermit
  25. is 5A(190).
  26.  
  27. The most common reason for failed uploads is inadequate buffer capacity on the
  28. receiving end, probably the Penril device in this case, coupled with the lack
  29. of an effective means of flow control.
  30.  
  31. Solution: reconfigure the communications server to have big buffers in the
  32. receiving direction as well as in the sending direction, and enable the
  33. most effective possible means of flow control (preferably RTS/CTS) between
  34. this device and the one it is most immediately connected to (presumably a
  35. modem).  Same deal on the calling end.
  36.  
  37. If the Penril and/or modem are unfixable, then use end-to-end Xon/Xoff flow
  38. control, which is less satisfactory as it is subject to latency and loss,
  39. and reduce Kermit's packet size until transfers start to work.
  40.  
  41. If that's not it, then maybe we have a transparency problem, but let's try
  42. this approach first.
  43.  
  44. - Frank